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IN THE TITLE 

Please insert the title - - A METHOD AND APPARATUS FOR MANAGING 
FUNCTIONS - 



IN THE SPECIFICATION 

Please delete the paragraph on page 27, beginning at line 13. 

Please replace the paragraph at page 12, line 1, with the following rewritten 
paragraph: 

In addition, Figure 1B shows metadata objects 120A-i associated with 
underlying functions. Particularly, metadata objects 120A and B respectfully 
identify action units 105A and B. Additionally, Figure 1B shows metadata object 
120C directly stores one of the functions (also referred to as an internal 
function), and therefore does not need an action unit. Among other things, a 
metadata object can store information describing the input and output 
"parameter kinds" to it's underlying function. It is worthwhile to note that the term 
parameter kind is not used herein as synonymous with data type. Rather, the 
phrase parameter kind refers to a type of information (e.g., name, street address, 
Id). Thus, two different parameter kinds (e.g., name and street address) may 
share the same data type (e.g., string). 

Please replace the paragraph beginning at page 12, line 10, with the following 
re-written paragraph: 

A metadata object typically does not contain the values to be used as 
input parameters to the underlying function. Rather, an execution object is 



formed to maintain a context (e.g., input parameter values and resulting output 
parameter values) for an underlying function. As such, one or more execution 
objects may be associated with each METADATA object. Figure 1 B shows 
EXECUTION objects 1 25A-X - 1 25i-x. Particularly, Figure 1B shows 
EXECUTION objects 125A-A through 125A-I identifying METADATA object 
120A, EXECUTION object 125B identifying METADATA object 120B, 
EXECUTION object 125C identifying METADATA object 120C, and 
EXECUTION object 125i identifying METADATA object 120i. 

Please replace the paragraph beginning at page 14, line 1, with the following re- 
written paragraph: 

With regard to the set of keys used to distinguish the parameter kinds, 
each function being tracked by the integration layer can have one or more input 
parameters and one or more output parameters. A naming convention is used 
for the different parameter kinds used by the functions. Different functions may 
share one or more of the same parameter kinds. To illustrate, consider the 
previous example where function A has as parameters an Id and a street 
address, while function B has as parameters a name and a street address. In 
this example, functions A and B share the street address parameter (they share 
the same parameter kind). In addition, this example has three parameter kinds 
(Id, street address, and name). 

Please replace the paragraph beginning at page 23, line 17, with the following 
re-written paragraph: 



The EXECUTION class 900 of Figure 9 includes the following structures: 
NAME; CLASS_LABEL; PARAMS; M ETAD ATA_0 B J ECT_PT R ; and 
MANAGER_PTR. As previously described, each execution object is associated 
with a metadata object. In one embodiment, the NAME structure of an execution 
object contains the same data as the name structure of the METADATA object to 
which it is associated. In alternative embodiments, the NAME structure need not 
store the same data, but rather a name to name look-up structure is used. The 
CLASSJ-ABEL structure of the EXECUTION class 900 is used for the same 
purpose as the CLASSJ-ABEL structure of the METADATA class. 

Please replace the paragraph beginning at page 26, line 1 8, with the following 
re-written paragraph: 

Figures 1 1 A-B are block diagrams illustrating two additional classes of the 
integration layer of Figure 1 A according to one embodiment of the invention. 
Figure 1 1 A is a block diagram illustrating a context class 1 100 according to one 
embodiment of the invention. The context class includes the following 
structures: NAME; KEY_VALUE_COLLECTION; and 
EXECUTION_COLLECTION. 

Please replace the paragraph beginning at page 27, line 22, with the following 
re-written paragraph: 

Figure 1 1B is a block diagram illustrating a MANAGER class according to 
one embodiment of the invention. A manager object can be used for managing 
the execution objects. The MANAGER class 1110 includes the following 



structures: CONTEXT.COLLECTION; DEFAULT_CONTEXT; 
EXECUTION_COLLECTION; and EXECUTION_PATH_COLLECTION. 

On page 28 beginning at line 18, please insert the following paragraph: 

The EXECUTION_PATH_COLLECTION structure is an ordered collection 
of level objects used to store a selected execution path. An ordered collection is 
one that includes data to indicate an order to the object stored therein. A level 
object is a collection of execution objects for a given level of an execution path. 
With reference to the previous example shown in Figure 21 , the execution path 
(A-> B-» E^) would be made up of four level objects (one per function) E. 
A more complex execution path can have more than one execution object per 
level of execution path, and EXECUTION_PATH_COLLECTION structure is 
further described later herein. 

Please replace the paragraph beginning at page 52, line 10, with the following 
re-written paragraph: 

Figure 20 is a block diagram illustrating the P ARAM ETE R_SATIS FY 
method according to one embodiment of the invention. The 
PARAMETER_SATISFY method receives the same inputs as the 
FIND_BY_NEED method previously described (see block 1700). From block 
2000, control passes to block 2005. 

Please replace the paragraph beginning at page 53, line 17, with the following 
rewritten paragraph: 
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Specifically, the common concept of encapsulation in object technology is 
to place data with its' associated methods together in a single object. In 
contrast, the integration layer is developed such that those methods that express 
a relationship (referred to herein as "relationship methods") are placed in 
separate objects — the relationship objects. In this manner, a higher degree of 
encapsulation is provided. While relationship methods within relationship objects 
are similar to methods commonly found in object technology in that they can be 
applied to the objects that contain them, relationship methods within relationship 
objects are different in that they often are applied to other objects, including base 
objects and other relationship objects. For a further description of relationship 
objects, see "A Method and Apparatus for Providing Relationship Objects and 
Various Features to Relationship and Other Objects," filed September 30, 1998, 
by Bhalchandra Ghatate, which is herein incorporated by reference. 



IN THE CLAIMS: 

Please cancel claims 2-46 with out prejudice 



REMARKS 

Applicant respectfully submits that no new matter is added. 



Charge Deposit Account 
Please charge any shortages and credit any overages to Deposit Account 
No. 02-2666, including any shortages caused due to insufficient funds for an 
M= accompanying check. Any necessary extension of time for response not already 

O requested is hereby requested. Please charge any corresponding fee to Deposit 

% i Account No. 02-2666. 
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M= Respectfully submitted, 
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Seventh Floor 

Los Angeles, CA 90025-1026 
(408) 720-8300 
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VERSION WITH MARKINGS TO SHOW CHANGES MADE 



IN THE TITLE 

A title was added. 

IN THE SPECIFICATION 

The paragraph beginning on page 27, line 17 has been deleted. 

Please replace the paragraph at page 12, line 1, with the following rewritten 

paragraph: 

In addition, Figure 1B shows metadata objects 120A-i associated with 
underlying functions. Particularly, metadata objects 120A and B respectfully 
identify action units 105A and B. Additionally, Figure 4- IB shows metadata 
object 120C directly stores one of the functions (also referred to as an internal 
function), and therefore does not need an action unit. Among other things, a 
metadata object can store information describing the input and output 
"parameter kinds" to it's underlying function. It is worthwhile to note that the term 
parameter kind is not used herein as synonymous with data type. Rather, the 
phrase parameter kind refers to a type of information (e.g., name, street address, 
Id). Thus, two different parameter kinds (e.g., name and street address) may 
share the same data type (e.g., string). 

Please replace the paragraph beginning at page 12, line 10, with the following 
re-written paragraph: 

A metadata object typically does not contain the values to be used as 
input parameters to the underlying function. Rather, an execution object is 
formed to maintain a context (e.g., input parameter values and resulting output 



parameter values) for an underlying function. As such, one or more execution 
objects may be associated with each METADATA object. Figure 1B shows 
EXECUTION objects 125A-X - 125i-x. Particularly, Figure 1B shows 
EXECUTION objects 125A-A through 125A-I identifying METADATA object 
120A, EXECUTION object 42§B~A 125B identifying METADATA object 120B, 
EXECUTION object 125C identifying METADATA object 120C, and 
EXECUTION object 42§i~A 125i identifying METADATA object 120L 

Please replace the paragraph beginning at page 14, line 1 , with the following re- 
written paragraph: 

With regard to the set of keys used to distinguish the parameter kinds, 
each function being tracked by the integration layer can have one or more input 
parameters and one or more output parameters. A naming convention is used 
for the different parameter kinds used by the functions. Different functions may 
share one or more of the same parameter kinds. To illustrate, consider the 
previous example where function A has as parameters an Id and a street 
address, while function B has as parameters a name and a street address. In 
this example, functions A and B share the 14 street address parameter (they 
share the same parameter kind). In addition, this example has three parameter 
kinds (Id, street address, and name). 

Please replace the paragraph beginning at page 23, line 17, with the following 
re-written paragraph: 

The EXECUTION class 900 of Figure 9 includes the following structures: 
NAME; TYPE CLASS LABEL ; PARAMS; METADATAJDBJECT_PTR; and 



u,. 



MANAGER_PTR. As previously described, each execution object is associated 
with a metadata object. In one embodiment, the NAME structure of an execution 
object contains the same data as the name structure of the METADATA object to 
which it is associated. In alternative embodiments, the NAME structure need not 
store the same data, but rather a name to name look-up structure is used. The 
CLASSJ-ABEL structure of the EXECUTION class 900 is used for the same 
purpose as the CLASS_LABEL structure of the METADATA class. 

Please replace the paragraph beginning at page 26, line 18, with the following 
re-written paragraph: 

Figures 1 1 A-B are block diagrams illustrating two additional classes of the 
integration layer of Figure 1 A according to one embodiment of the invention. 
Figure 1 1 A is a block diagram illustrating a context class 1 100 according to one 
embodiment of the invention. The context class includes the following 
structures: NAME; KEY_VALUE_COLLECTION; and 
EXECUTlON„COLLECTlON~and E X E C UT ION JATH^COLLECTION . 

Please replace the paragraph beginning at page 27, line 22, with the following 
re-written paragraph: 

Figure 1 1 B is a block diagram illustrating a MANAGER class according to 
one embodiment of the invention. A manager object can be used for managing 
the execution objects. The MANAGER class 1110 includes the following 
structures: CONTEXT_COLLECTION; DEFAULT_CONTEXT; and 
EXECUTION COLLECTION ; and EXECUTION PATH COLLECTION . 
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A paragraph was added beginning at page 28, line 18. 

Please replace the paragraph beginning at page 52, line 10, with the following 

re-written paragraph: 

Figure 20 is a block diagram illustrating the PA RAM ET E R_S AT I S FY 
method according to one embodiment of the invention. The 
PARAMETER__SATISFY method receives the same inputs as the 
FINDJ3YJSIEED method previously described (see block 2000 1700 ). From 
block 2000, control passes to block 2005. 

Please replace the paragraph beginning at page 53, line 1 7, with the following 
rewritten paragraph: 

Specifically, the common concept of encapsulation in object technology is 
to place data with its' associated methods together in a single object. In 
contrast, the integration layer is developed such that those methods that express 
a relationship (referred to herein as "relationship methods") are placed in 
separate objects— the relationship objects. In this manner, a higher degree of 
encapsulation is provided. While relationship methods within relationship objects 
are similar to methods commonly found in object technology in that they can be 
applied to the objects that contain them, relationship methods within relationship 
objects are different in that they often are applied to other objects, including base 
objects and other relationship objects. For a further description of relationship 
objects, see "A Method and Apparatus for Providing Relationship Objects and 
Various Features to Relationship and Other Objects," filed — 
September 30, 1998 , by Bhalchandra Ghatate, which is herein incorporated by 
reference. 
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IN THE CLAIMS: 

Claims 2-46 have been cancelled without prejudice. 
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